|
|
pastedImage.png (17,725 bytes) |
|
|
Hi Wooshin, We have one question, in the current code (Both eagle/swan), SPtek has already implemented unpair function for cross paring. For example: Step 1: A RCU is pared. Step 2: Press paring key on B RCU Step 3: B RCU will be paired and connected Step 4: A RCU will be disconnected and unpaired by middle ware. I have no idea why SKB want to implement unparing function again ? According to the discussion in Wechat, it seem that SKB want clear RCU information in the previous RCU. if so, I think Sptek should handle this request, because in the current code, middleware is in charge of handling the behavior of crossing paring. If they want to handle it by Foxconn, before the middleware disconnect/unpair the previous RCU, they should notify us, otherwise, if middle disconnect/unpair the previous RCU, the connection is boken, we can NOT send any ATT command to previous RCU for clear RCU information. If SPtek can not handle this request by themselves, I think the follow will be: Step 1: A RCU is pared. Step 2: Press paring key on B RCU Step 3: B RCU will be paired and connected Step 4: Sptek will notify Foxconn that they are ready to disconnect/unpair the A RCU Step 5: Foxconn send the "clear information" command to the A RCU (if the ack from the previous is OK, Foxconn will notify the Sptek that they can start disconnect/unpair the A RCU) Step 6: A RCU will be disconnected and unpaired by middle ware. (Now this step is handled by middleware) |
|
|
Hi Jason, I have no idea why SKB want to implement unparing function again ? -> In this case, pairing data of RCU in not cleared. Clearing data of RCU is purpose for this implementation. if so, I think Sptek should handle this request, because in the current code, middleware is in charge of handling the behavior of crossing paring. -> Sptek will handle it, Sptek will call API with saved data ( Name or MAC of RCU ) of previous RCU. API is implementation by FXN, it could be sent command of attached table to previous RCU. So, API should be implemented like below. 1. API in bt stack will be made. 2. It will connect with method of BT service layer. 3. APK of SPTEK can call method of BT service layer. Thanks. |
|
|
Hi Wooshin, It is not necessary to make API in BT stack. The apk can establish GATT connection and sent ATT command to BT device. (For example, iSet is an apk, it can send ATT command to RCU, We haven't modified anything in BT stack for iSet feature) so I think Sptek can implement ATT command in their APK, We don't need to add new API in bt stack. |
|
|
Hi Jason, ok, if don't need to implement it, Please guide about usage. SPTEK doesn't know about this. Thanks. |
|
|
Hi Wooshin, the keyword are BluetoothDevice, BluetoothGatt and BluetoothGattCharacteristic, I think they can find some sample codes on Google. According to your table, For field Opcode (write): use API BluetoothGatt.writeCharacteristic For field ATT: before you write Characteristic, you MUST make GATT connection to RCU. use API BluetoothDevice.connectGatt For field Payload: packetize it in BluetoothGattCharacteristic, use API BluetoothGattCharacteristic.setvalue(payload); Thanks. |
|
|
SPTEK found the other solution. |
- yk.jung ( (ALTech) Younkwang Jung ) developer
.png)
